System and method for network operation

ABSTRACT

A network of secure servers, requiring no central entity to administer user identities or access permissions. Each autonomous server hosts a set of user accounts. Users may link to and access the accounts of all other users in the network. Resources in accounts are private, but users may grant each other partial permissions to them. Links and permissions are independent of the location of accounts, and are cryptographically authenticated. Users may migrate their account between servers without loosing accumulated permissions, or breaking links that others have to their account. The ability to grant permissions may be delegated to reflect complex organizational structures. A permission may be configured to unlock data in a multitude of accounts. The system will support applications that require secure information sharing across multiple organizational boundaries, and provides a distributed security model which is feasible to deploy as it is wholly administered by its users.

This application is a continuation of U.S. Ser. No. 10/172,169, filedJun. 14, 2002.

FIELD OF THE INVENTION

This invention relates to secure networks, the management of accesspermissions without central authorities, and location independence ofdata and users.

BACKGROUND OF THE INVENTION

The world wide web has allowed information to be easily exposed toanyone worldwide. Difficulties arise when one does not want theinformation to be accessible to the entire Internet community. Thepublisher of a document cannot easily define who should or should nothave access to it. Various controls are deployable to add security andrestrict access to a defined group of users, yet secured systems aregenerally isolated from each other, representing distinct groups ofusers. A user identity and password on one system will generally have nomeaning on another system.

Information in one secured system is generally unavailable to the usersof another secured system. This is often desirable. However, there arenumerous examples where the converse is a core requirement. Forinstance, there may exist sensitive documents that should be availableto the staff of an enterprise. Typically, these documents are onlyaccessible by users of particular system on which they reside. Staff inother divisions or territories are not recognized by that system. Evenless are third parties who should also have secure access to thedocuments. Such situations present a distinct security problem becauseusers and/or resources are not within the same security authority. Acommon solution is to create an overarching system such as an intranetthat centralizes data and users. Unfortunately this is an impracticableway to represent the numerous relationships that coexist betweenindividuals, enterprises, an other entities.

The choice of email provider is an illustrative parallel. Ifcommunicants needed to be registered with the same provider to send andreceive each others' messages, the technology would be of littlerelative worth. A person's choice of provider is not based on theindividuals they might wish to communicate with. These are in any casedispersed across a profusion of other providers.

Users also migrate between service providers and have to relinquishtheir previous user identity. Email fails here, as email addresses arenot transferable between domains. Generally, changing one's networklocation implies having to re-establish the basis of electronicrelationships with other users if one's network identity is the basis ofsecurity permissions.

The distributed nature of the internet presents a distinct problem withregards to the management of users' access to each others' private data.Whereas technologies such as SSL/TLS, SSH, and IPSEC effectively managesecure one-to-one communication between authenticated systems, they donot address the problem of many-to-many access permissions. There arevarious approaches to this particular problem in the art. Typically,they involve a central entity acting as an authority over a network.This authority either authenticates user identities or acts as anendorser of identities as worthy of ‘trust’.

An example of a centralized authentication entity is the Kerberossystem, (Kohl, J. and C. Neuman, “The Kerberos Network AuthenticationService (V5)”, RFC 1510, 1993). Whilst this approach is applicablewithin a single organization, there are objections to its use acrosslarger networks. Firstly, it is antithetical to the nature of theInternet, which owes its unbounded scalability to its highlydecentralized structure. A technology whose value is dependant on amonopoly of its function suffers scalability problems and is an unstablesolution as a network expands. Secondly, the namespace of useridentities is necessarily owned by the central entity. This isproblematic if one's network identity (and thus one's ability to accessresources) is ultimately controlled by an entity to which one may not beaccountable, or whom one does not desire as an intermediary.

Private Key Infrastructure (PKI) is an example of a central entity thatacts to endorse user identities as worthy of ‘trust’. This is a usefultool for authentication, i.e. the binding of the real name or user nameof an individual to a public key in a digital certificate. Theendorsement of an authority is however only of value if the authority istrusted by the target system. This suggests the need for multipleauthorities. The resulting burden of certificate management isunfortunately beyond the scope of most organizations or systems,particularly as PKI is a difficult model to successfully automate.Furthermore, PKI authorities endorse identities, not access rights. Theycannot easily manage these rights or express them in a unified way forconsumption by a diversity of target systems.

Approaches that address the problem of authentication without centralauthorities are Pretty Good Privacy (‘OpenPGP Message Format’, J.Callas, L. Donnerhacke, H. Finney, R. Thayer, RFC 2240, November 1998)and Simple Public Key Infrastructure (‘SPKI Certificate Theory’, C.Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen, RFC2693, September 1999). These approaches are compelling butadministratively complex from the perspective of a user. The latter doesallow the specification of authorization rights, but does not propose asingle simple unified method for this. Particularly, it is importantthat an authorization right be understood by more than one system.Consider the case of a group of individuals who each wish to securelyexpose documents to each other. This should be feasible withoutknowledge of the nature of each others system.

If secure access rights are to be granted to a certain class ofdocument, one would hope this permission could be specifiedindependently of their actual location. For example, documents forconsumption by senior staff should be generally classifiable as such,but not solely by virtue of their residence on a particular server. Theymay indeed exist in multiple locations. One should be able to relocatedata to another system without affecting the permissions that otherusers may have to it. There exist in the art approaches to theseparation of document identifiers from their locations. The HandleSystem (“Handle System Protocol v2.0 Specification”. S. Sun, S. Reilly,L. Lannom, J. Shi, IETF Internet Draft, April 2001) provides a way ofresolving a location independent document identifier into its networklocation. These initiatives ultimately rely on central services whichare subject to the scalability issues already mentioned, and are notdesigned to address intra-user security issues.

When conceiving a distributed network of users and their private data,the systems in the prior art have inherent problems when faced with thecombined requirements that: (1) it be a centerless network, (2) accessto data may be restricted to specific users, (3) such users may behosted anywhere else in the network, (4) user identities are not tied totheir current choice of service provider, (5) access rights be specifiedwithout reference to data or user location, and (6) access rights besimple to administer by the users themselves. Therefore, an improvedsystem and method are needed to enable effective operation within thesecommon requirements. In particular, the present invention is a systemthat inherently fulfills all the foregoing requirements.

SUMMARY OF THE INVENTION

A system for supporting a distributed network of private resourcesaccording to one aspect of the invention includes a plurality ofservers, suitable means permitting data communication between a user andeach of the servers, a plurality of user accounts hosted on each server,a plurality of private resources stored on each server within each useraccount, a plurality of realm names used to classify the privateresources, the realm names spanning any number of user accounts, andsuitable means (typically client-server system software) for a firstuser account to grant a second user account hosted on any of the serversa permission to access all private resources classified by a realm name,if the realm name was created by the first user account, or optionallyif the first user account had the right to grant such permissiondelegated to it. The means for permitting data communication may be anyconventional data connection, such as the Internet, over a LAN or WAN,which may be wireless or use cables, or a direct data connection. Acorresponding method for supporting a distributed network of privateresources involves designating a plurality of realm names used toclassify the private resources, the realm names spanning one or moreuser accounts, and permitting a user account to grant another useraccount hosted on the server a permission to access all privateresources classified by a realm name, if the realm name was created bythe first user account, or optionally if the first user account had theright to grant such permission delegated to it.

According to preferred embodiments of such a system, the user accountsare allocated a globally unique account identity including a globallyunique number and a public key from an asymmetric cryptographic keypair. Software running on the server can generate network identitiesautonomously, without involvement of any naming authority and withoutneed to compare the new network identity with a list of existing ones. Atemporary association is made between an account identity and thelocation (e.g., URL) of the server that hosts it. These associations arecommunicable to the servers and verifiable by the servers, and useraccounts may migrate between the servers without relinquishing theiraccount identity. Permissions to access private resources are specifiedregardless of which server currently hosts the user accounts of theissuer and recipient of the permission. The permission enables access toall the private resources classified by the realm name specified in thepermission, irrespective of which user account uses the realm name toclassify the private resources.

A preferred configuration for supporting such a distributed network ofprivate resources according to the invention includes a plurality ofserver software applications running on a plurality of first computersfunctioning as servers, a plurality of client software applicationsrunning on a plurality of second computers functioning as clients, whichmay be the same as or different from the first computers, and suitablemeans permitting data communication between client software applicationsand each of the server software applications. The client softwareapplications can be used by users to establish sessions to send andreceive data from server software applications.

The invention further provides a system for supporting a distributednetwork of private resources including a plurality of servers, meanspermitting data communication between a user and each of the servers, aplurality of user accounts hosted on each server, and means forautomatically generating for each user an account identifier that isglobally unique in the network, which means constructs the globallyunique account identifier without reference to existing global accountidentifiers already in use on the network. The account identifierpreferably comprises a globally unique number and a public key from anasymmetric cryptographic key pair. A corresponding method formaintaining user accounts in a network comprises automaticallygenerating for each user an account identifier that is globally uniquein the network by constructing the globally unique account identifierwithout reference to existing global identifiers already in use on thenetwork. Each account identifier is associated with a location on one ofthe servers, and can be transferred from one server to another whilemaintaining the same globally unique account identifier.

In another aspect, the invention is applied to a system for maintaininguser contact information. Such a system includes at least one server,means permitting data communication between the server and a number ofelectronic devices that maintain or use contact information, each devicebeing enabled with the necessary client functionality, and a pluralityof user accounts hosted on the server, each account containing a listingof current contact information for the associated user, and a contactlist of identifiers for selected other users having accounts hosted onthe server. In a preferred embodiment, a first user account may grant asecond user account permission to access that user's contactinformation; otherwise such access is not permitted. The user-controlledelectronic devices may be portable telephones, personal computers(desktop or hand held) or the like. A corresponding method formaintaining user contact information includes the steps of maintainingfor each user account a listing of current contact information for theassociated user, and maintaining a contact list of identifiers forselected other users having accounts hosted on any of the servers, whichcontact list can be accessed by the electronic device used by that user.These and other aspects of the invention are discussed in the detaileddescription that follows.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates in block diagram form the architecture of thecomponents of the system of the present invention and the environment inwhich it operates.

FIG. 2 illustrates in flow diagram form the operational steps of thelogin process which established a session with a server.

FIG. 3 illustrates in flow diagram form the operational steps of thesession reactivation process.

FIG. 4 illustrates in flow diagram form the operational steps whereby aresolver for a particular account is pulled from a server, given theaccount's SecureGUID.

FIG. 5 illustrates in flow diagram form the operational steps whereby aresolver for a particular account is pulled from a server, given theaccount's name.

FIG. 6 illustrates in flow diagram form the operational steps whereby aresolver for a particular account is pushed to a server.

FIG. 7 illustrates in flow diagram form the operational steps wherebythe methods of pulling and pushing a resolver are combined.

FIG. 8 illustrates in block diagram form a folder tree with realmdefinitions.

FIG. 9 illustrates in flow diagram form the operational steps wherebyrealms control the behavior of methods called within guest sessions.

FIG. 10 illustrates in flow diagram form the operational steps whereby acertificate is pushed to a target server.

FIG. 11 illustrates in flow diagram form the operational steps whereby acomplete certificate, comprising one or more grants, is retrieved from aserver.

FIG. 12 illustrates in tabular form the maintenance actions that areapplied to the various grants types.

DETAILED DESCRIPTION

The present invention contemplates a network which has no center. It isa server system which can be duplicated in an any number of locations.Adding another server requires no authorization from any centraladministrative entity. Each service provider is thereforeadministratively autonomous. Users identities are created locally byservers, yet are globally unique and consistent with those on all otherservers. All user identities are therefore recognizable by all servers.Users may migrate to another server without having to relinquish theirexisting identity.

All data placed by a user on a server is private by default. Users maysecurely expose a subset of this data to specific other users. It mayalso be generally exposed to any user who has permission to a certainclass of data. Access rights may be granted to any user in the network,not just those registered on the same server. The ability to grant theright may itself be delegated, to reflect more complex organizationalstructures. Permissions given to users grant them access to a particularrealm of data. This realm may be used to classify data in any number oflocations. The access right is therefore independent of the actuallocation of data.

The present invention is capable of supporting applications that requiresecure information sharing across organizational boundaries. Threeexamples follow. Firstly, contact management systems that pull privatecontact information from other users irrespective of their networklocation, negating the need to maintain data about other users since thedata is maintained by at source by the users themselves. Secondly,secure file sharing applications allowing file exchange across multipleorganizations, negating the need to unify those organizations' securefile systems. Thirdly, secure messaging systems that allow users todeposit authenticated messages in each others accounts.

The invention is aimed at processes that depend on controlled access todistributed data. It proposes a distributed security model which iswholly administered by its users, with no dependency on central entitiesor third party authorities. Further objects and advantages will becomeevident from consideration of the detailed description and drawings. Theinvention is further aimed at a network of secure peer servers,requiring no central entity to administer user identities or accesspermissions between users.

The system of the present invention can be implemented by a distributedplurality of computing devices as illustrated in FIG. 1. Each serverhosts a plurality of user accounts, and serves private files from thoseaccounts. Clients act on behalf of users to request resources fromservers. This may be specified differently in an alternative embodiment,for instance as a composite entity that serves both roles. For purposesof the present invention, “resources” include files saved on a server,data contained within such files, application objects, network services,dynamic content, and any other form of data, information or softwarecode that can be made available on a server for other users to access. Aplurality of isolated servers exist in an arbitrary number. Only twoservers 110 and 111 are shown in FIG. 1, but the number of supportableservers is unlimited. These are peers, i.e. there is no hierarchy acrossservers and there are no central components in the network. Each servercomprises a firewall 104, a Hyper Text Transfer Protocol (HTTP)interface 105, the server application software 108, and a database 109.

A client 103 can invoke methods on any server in the network. A clientis however specially associated with a particular server, by virtue ofhaving a ‘gateway’ account on it. This allows the client to create useraccounts on the server. Each client comprises a firewall 104, a HTTPinterface 105, the client application software 106, and an optional keystore 107. Users interact with servers via client 103. Users have anaccount on single server. FIG. 1 shows a single user 100, althoughnumerous users may exist with accounts distributed across a multitude ofservers. Users access their account via the client associated with theserver that hosts it. Typically the client holds cryptographic keys inkey store 107. These keys allow the user to login to their account.Users invoke a client via an intermediary device, for example a webbrowser 101 run on a local PC or a dedicated agent application with agraphical user interface.

In this preferred embodiment, the system comprises distinct server andclient components. Each such component includes both a physical machine(computer) and software running on that machine that provides the clientor server functionality. However, as persons skilled in the art willrecognize, client and server programs could be run on the same machine,which would effectively act as both client and server. It is evenpossible in simplified forms of the invention to provide clientfunctionality at the user level (e.g., on the personal computer used tocommunicate with the network). There would not necessarily have to be aseparate client software application acting as a intermediary betweenuser and server, and server software could be designed to exchange datapeer to peer with other servers, rather than by means of the describedclient software application. However, the client-server architecturedescribed herein is highly efficient and functional.

The system methods described herein are invoked by clients on servers,across a network connection indicated in FIG. 1 by the Internet 102. Inthe preferred embodiment, these are conducted as remote procedure callsusing Simple Object Access Protocol (SOAP), carried over HTTP. Othermethod invocation processes may be employed in alternative embodimentsof the system. As HTTP protocol is inherently stateless, the servershave a method to create and manage the state of client sessions. Allmethods are thus parameterized by a session identifier. These methodsare all synchronous.

All network traffic between clients and servers is carried out using theSecure Sockets Layer protocol (The SSL Protocol Version 3.0, Freier,Karlton, Kocher, Nov. 18, 1996). This is used for packet encryptiononly, to prevent against eavesdropping on network traffic. Theauthentication mechanism of SSL is not used. It is therefore notnecessary that certificates be used to authenticate either party'spublic keys. All the authentication requirements are implemented at ahigher level by the system itself.

Each user of the system has an account on a single server. An accountprovides the user with a proprietary file store. The user is allocated acryptographic key pair, stored on the server. The user is expected tohave access to a copy of the keys to authenticate themselves as theowner of their account, in order to login to it. The process of keyallocation is described in the New Accounts section.

There are numerous possible approaches to structuring the file store ina user account. In the preferred embodiment, it is structured as a treeof ‘folders’ managed by a relational database. Each folder may contain asingle arbitrarily sized binary file. It may also refer to a singleother folder as its ‘parent’. Multiple ‘sibling’ folders may have thesame parent. This ensures a well formed tree representation in whicheach folder is identified by an unambiguous path of ancestor folders.Each folder record has the following attributes or fields:

-   1. Folder Identifier, unique to the database-   2. Parent, a reference to the folder identifier of the parent folder-   3. Folder Name, unique across its siblings,-   4. MIME-type of the binary data field-   5. Descriptive name-   6. Alias account, a reference to another account.-   7. Alias folder, a reference to a folder identifier in the other    account.-   8. Binary Data    The fields 1 through 7 are referred to collectively as the ‘header’    of the folder. A folder is either referenced by its folder    identifier, or by a sequence of folder names forming a path to the    folder.

The network consists solely of a plurality of peer servers, so nocentral entity is available to provide a uniform naming service. Aserver itself is therefore responsible for creating identifiers for theaccounts that it hosts. Because all accounts on all servers are equallyaddressable by all clients, it is crucial that these identifiers be a)unique across all servers, and b) resistant to impersonation bymalevolent agents. The approach is to define a secure globally uniqueidentifier, or ‘SecureGUID’. This is a composite of the following twocomponents:

1. A 128 bit UUID (Universally Unique IDentifier), defined in ISO/IEC11578:1996, ‘Information technology—Open Systems Interconnection—RemoteProcedure Call (RPC)’. Particularly, the preferred algorithm forconstructing these identifiers contains the following items:

-   -   a) a 48-bit hardware serial number of the network card on the        computer running the server (generally referred to as the IEEE        or MAC address). This is unique to each network card.    -   b) a 60-bit a time stamp represented by Coordinated Universal        Time (UTC) as a count of 100 nanosecond intervals since 15 Oct.        1582.    -   c) a 14-bit sequence number, incremented if the system clock has        been tampered with or the network card has been exchanged since        the last UUID was generated.        The sequence number protects against the possibility of        identical UUIDs subsequent to either of these events. This is        initialized with a random number, and reinitialized if its        current state is ever lost. The remaining 6 bits of the UUID are        reserved for version information.

2. The public key from the account's asymmetric cryptographic key pair.The particular choice of cryptographic algorithm is not specified. Itmust however be chosen such that it is computationally infeasible to anyreasonable degree to determine a private key given its associated publickey.

It is axiomatic that SecureGUIDs do not themselves directly act asnetwork locators, in the in the manner that email addresses or web URL'sdo. This allows accounts and their data to migrate between serverswithout needing to relinquish their SecureGUID. Notably, the hardwareserial number of the network card is not used to relate the account to aserver, despite being a constituent of the UUID in a SecureGUID. TheSecureGUID may have been generated by a server from which the accounthas since migrated. The method for expressing location information foraccounts is covered in the resolvers section.

Under normal operation of the system, the event that two SecureGUIDsshare either the same UUID or the same public key has realistically zeroprobability. This eventuality is not problematic if both items are notidentical, as the accounts would be considered as having distinctidentities. Both being identical would result in a collision of accountidentities, yet the probability of this is also realistically zero undernormal operation of the system. A software hacker that acquires both theSecureGUID and private keys of an account may be in a position toconstruct a bogus account that effectively duplicates and impersonatesit. This is the case with any security model that relies on the secrecyof a key, including both asymmetric and symmetric key based systems. Theability to keep the private key secret is therefore assumed.

Accounts additionally have a short name, typically selected by the user,which is only unique across accounts hosted on a particular server. Thisname may need to be changed if the account is migrated to another serverthat already has an account using the same name. The name is a humanreadable index to the account's SecureGUID, and is never used outside ofthe namespace of the particular server. A user may inform another userof their account identity and its current location by quoting theiraccount name and server URL, much like an email address. The accountname and server URL combination is strictly treated as an ephemeralidentifier, useful only by virtue of its human readability and easydistribution. Unlike a SecureGUID, it does not survive the migration ofthe account nor embody its cryptographic identity. Clients performone-off translations of these name/URL combinations into SecureGUIDs, asdescribed in the pulling a resolver from an account name section below.

The login process permits a user, via a client, to establish a sessionwith a target account on a target server. The identity that a userpresents is the SecureGUID of their own account. The resulting sessionmay allow the user to retrieve and manage files contained in the targetaccount. There are two types of session that result from the loginprocess:

-   -   1. ‘Owner session’. This is the case where the user logs into        their own account, i.e. the presented user identity is identical        to the SecureGUID of the target account. The user is considered        to own the target account, and the session allows them full        access to all folders within the target account's folder tree.    -   2. ‘Guest session’. This is the case where the user logs into        another user's account, i.e. the presented user identity differs        to the SecureGUID of the target account. The session allows        restricted access rights to folders within the target account's        folder tree. These restrictions are a function of permission        certificates that have been granted to the user, and which the        user will be required to present.        To successfully complete the process, the client must prove to        the server hosting the target account that it currently has the        private key associated with the user's SecureGUID. In the        typical case, the client stores the key on behalf of the user in        key store 107 of FIG. 1. Alternatively, users may wish to store        private keys themselves, for instance on a portable medium such        as a smart card. In the latter case, they would temporarily        introduce the private key to the client prior to the session,        and remove it after terminating the session.

The process is illustrated in FIG. 2. In step 202, a client 103 submitsthe session initiator's account SecureGUID and a target account'sSecureGUID to a server 110. Step 203 checks that an account with thetarget SecureGUID is hosted on the server 110. If so, a locally unique32-bit random number or ‘nonce’ is generated in step 204. This nonceuniquely indexes a newly created session. The state of this session iscreated in step 205 and stored in database of sessions. Each sessioncontains the following fields:

-   1. Nonce-   2. Initiator SecureGUID-   3. Target SecureGUID-   4. Folder lock list-   5. Realm stamp list-   6. Expiry time    The expiry time field is initialized in step 205 to the current    clock time of the computer operating the server 100. This implies    that the session is inactive, i.e. it has expired at the moment of    creation. In step 206, the nonce is returned by server 110 to client    103.

Client 103 must now activate the session by authenticating the usersidentity. It digitally signs the nonce using the user's private key instep 207. This signature is returned to the server 110 in step 208,parameterized by the nonce itself. In step 209, the session state recordindexed by the nonce is retrieved. A check is made that the current timeis earlier than the sum of the session's expiry time and a maximumactivation period. This period is determined in a configuration file onthe server 110.

The public key is extracted from the Initiator SecureGUID field and usedto decrypt the submitted signature in step 210. The decrypted signatureis compared to the nonce itself in step 211. If these are identical, theuser is considered to be authentic, insofar as the client 103 has provedthat it has access to the private key of the user's account. In step212, the expiry time in the session state is set to a fixed period aheadof the current time. This period determines the session's initiallifetime, and is specified in a configuration file on the server 110. Asession that has been activated allows methods to be invoked on thetarget account. All such methods must in each instance be parameterizedby the session's nonce.

The session nonce is only valid within the session's expiry time. Theexpiry time indexed by a session nonce is compared to the current systemclock time for each method call received by a server. An expiry time isin the past will result in the method failing. An expired session staterecord is however not immediately erased. It may be reactivated within aperiod specified in a configuration file on the server.

The expiry process provides a safeguard in the unlikely event that amalevolent party can both break the temporary SSL encryption key andguess or eavesdrop the 32-bit nonce of an active session. In this eventtheir window of opportunity would be limited to the session's expirytime, as the account private key is required to activate the sessionbeyond that period. The purpose of reactivation is to maintain folderlocks and realm stamps that the user may have been granted during thesession. Theses are detailed later in this description.

FIG. 3 illustrates the process of session reactivation. In step 250 theclient 103 submits the expired nonce to the server 110. The server 110checks that a session exists with this nonce in step 251. If so, in step252 a new locally unique 32-bit nonce is generated. In step 253 theexisting expired session is re-indexed with this number and the expirytime is set to the current clock time. Step 206 to 212 are identical tothose in FIG. 2. Note that client 103 must have remained in possessionof the user's private key to complete the session renewal process.

A client may store the private keys of users in a key store 107 ofFIG. 1. A user is in this case necessarily trusting the client to notuse the keys without the their own consent. The client has theresponsibility for authenticating users prior to retrieving theirprivate key and logging in on their behalf. The client may implement avariety of approaches to achieve this, for instance username andpassword or other third party authentication.

A client is associated with a particular server by virtue of having a‘gateway’ account. A gateway account has the attribute of allowing theaccount owner (i.e. the client) to create user accounts. The clientitself holds the private key for its this account, and authenticatesitself to the server using the login process. The method call to createa new account on a server will only succeed if parameterized by a noncethat indexes an active owner session for a gateway account. The methodreturns a SecureGUID and an encrypted private key for a new account,such encryption carried out using the public key of the sessioninitiator (i.e. the client). On receipt, the client decrypts the newaccount's private key using its own private key. If the client has a keystore, it uses it to persist the new account SecureGUID and private key,indexed by the appropriate credential. If not, it returns these to theuser. Typically, a pool of unallocated SecureGUIDs and private keys isinstalled on the server, which become allocated by the new accountmethod. This reduces the computational burden of generating asymmetrickey pairs on demand.

The following methods allow the user to browser and edit their foldertree and the data contained within folders. Each method is parameterizedby a session nonce and either a folder identifier or a folder path:

-   -   Read header—returns all attributes of the folder, excluding the        data field.    -   Read data—returns the data field of the folder    -   Read children—returns the attributes of all children of the        folder, excluding their data fields    -   Write header—writes the folder's attributes, excluding the data        field.    -   Write data—writes the folder's data field.    -   Remove folder—deletes the entire folder and all its child        folders    -   Remove data—deletes folder's data field        If the nonce that parameterizes a folder method indexes an owner        session, the method will unambiguously succeed (if correctly        specified). If it indexes a guest session, the method will        succeed only under certain conditions. These conditions are        described in the realms and guest sessions sections below.

The read header method can request a ‘folder lock’. The requested lockis specified either as a ‘write lock’ or as a ‘tree lock’. A write lockis requested if the user intends to edit and rewrite a folder to thesame location. A tree lock is requested if the user intends to move ordelete the folder, and by implication its descendants. A write lock isgranted on a folder if there is no other write lock on it, nor treelocks on it or on its ancestors. A tree lock is granted on a folder ifthere are no write locks on it or its descendants, nor tree locks on itsancestors, on it, or on its descendants.

In addition to these criteria, one of two conditions must be true. Thefirst is that the method is parameterized by a nonce that indexes anowner session. The second is that the method is parameterized by a noncethat indexes a guest session, and that the session has a ‘realm stamp’for a ‘read/write’ permission to the ‘realm’ that the specified folderis in. A lock is implemented by associating the folder with the sessionnonce of the user that has been granted the lock. The user mayexplicitly release the lock using a separate dedicated method.Otherwise, the lock expires by default when the user's session staterecord is garbage collected from the sessions database. This takes placewhen the session has remained inactive beyond the reactivation period.

Users need to be able to communicate their accounts' SecureGUIDs andhost server locations to each other, so that they may interact with eachothers' accounts. Account location information is crucial to theoperation clients, so that they may invoke methods relating to thoseaccounts on the correct target servers. The system uses a ‘resolver’data structure to associate accounts with their locations. A resolverexpresses location information for a specified account. Location in thiscontext means association with another entity. Resolvers genericallybind a ‘child’ to a ‘parent’. Resolvers relating to any account may bepulled from and/or pushed to any server, by any client.

Resolvers consist of the following fields, the use of which iscontingent on whether the resolver relates to a user account or agateway account:

-   1. Child-   2. Parent-   3. Challenge token (optional)-   4. Signature (optional)-   5. Signature algorithm (optional)    If the resolver relates to a user account, the child field is the    SecureGUID of the user account, and the parent field is the    SecureGUID of its associated gateway account. The resolver is thus a    statement that the specified user account is located on the same    server as the specified gateway account. If the resolver relates to    a gateway account, the child field is the SecureGUID of the gateway    account, and the parent field is the URL of the server hosting the    gateway account. The resolver is thus a statement that the specified    gateway account is located on a server with the specified URL.

In the case of user accounts, two resolvers are therefore required tomap an account SecureGUID to the URL of its host servers. The firstassociates the account to a gateway account, and the second associatesthe gateway account to a server URL. These two levels of indirectionallows a single resolver to communicate that a server has changed URL oran entire collections of user accounts has migrated between servers.Resolvers for user accounts are always bundled with the resolver fortheir associated gateway account.

An ‘unsigned resolver’ is only populated with the child and parentfields. Such a resolver is considered ‘unconfirmed’ by its recipient. Itis a means for a server to provide suggested location information forthe specified account, if it does not host the account but has itselfpreviously stored a resolver for it. A ‘signed resolver’ is one thatadditionally contains the challenge token, signature and signaturealgorithm fields. Such a resolver is considered ‘confirmed’ by itsrecipient, according to criteria described in the push resolver methodsection below. It is a means for a server to provide definitiveinformation on the current location of the specified account, if ithosts that account. The challenge token is a number provided by therequester of the locator. The signature field is a digital signaturecreated with the private key of the account refereed to in the childfield.

Each resolver is stored as a single record in a resolvers database on aserver. A server may store multiple resolvers for a given account ifthey differ in their parent field. Each record has a flag in thedatabase indicating its status. The possible values of this flag are‘unconfirmed’ and ‘confirmed’. Strictly one resolver per account may beflagged as ‘confirmed’. The remainder are flagged as ‘unconfirmed’. Only‘confirmed’ resolvers are used by the system as account locators.

If a resolver received by the push resolver method is signed andcontains a challenge token identical to the current session nonce, it isconsidered to be a confirmation of the account location. It proves thesource server's possession of account private keys and must necessarilyhave been created within the lifetime of the current session. Such aresolver is flagged as ‘confirmed’. All previous resolvers for the sameaccount are switched to ‘unconfirmed’. Additionally, each record has a‘date checked’ field. This is initially null.

Using this method, a resolver for any account may be requested by anyclient from any server. If the account is a user account, a resolver forits associated gateway account is bundled in the response. The processneed not take place within a session, i.e. the method is notparameterized by a session nonce. The server's response is contingent onone of three outcomes:

-   -   1. The requested account is hosted on the server.    -   2. The requested account is not hosted on the server, but the        server has a previously stored resolver for the account.    -   3. The requested account is not hosted on the server, and the        server has no knowledge of the account.        In the first case, where the account is hosted on the server,        the method returns a signed resolver for the account. Amongst        servers, the hosting server uniquely has access to the private        key of the account (and its associated gateway account if it is        a user account). It establishes its status as the hosting server        by using this key to sign resolvers for that account. To prove        that it has the key at the very moment the resolver is        requested, it includes in the signature a challenge token which        is supplied by the client invoking the method. In the second        case, the server has knowledge of the location of the account,        but it is not its host. It returns the resolver, but makes no        attempt to sign it (it does not have the private key that would        be required for signing). The client will subsequently repeat        the pull resolver method, this time invoked on the server        implied by the URL in the unsigned resolver. In the third case,        the server has no information which it can return to the client.

FIG. 4 illustrates the process, in which a client 103 pulls a resolverfor a particular account from a server 110. In step 352, the SecureGUIDof the account for which a resolver is required is submitted by client103 to server 110, with a challenge token. Step 353 checks that server110 hosts a user account with the specified SecureGUID. If so, aresolver is constructed in step 354. The challenge token is entered intothe resolver in step 355. The resolver is signed with the user andgateway account private keys in step 356. The signed resolver isreturned to the client 103 in step 357. The client validates theresolver and stores it in step 362. The process for validation isdescribed in the resolver signatures section below.

If step 353 establishes that server 110 does not host a user accountwith the specified SecureGUID, step 358 checks if a resolver for theaccount flagged as ‘confirmed’ is nevertheless stored on the server 110.If so, the resolver is retrieved in step 359. In step 360 it is returnedunsigned to client 103. The client 103 re-invokes the process in step363, on the URL of another server 365. This URL is contained in thereturned unsigned resolver. The process thus repeats until a signedresolver is returned. To prevent loops, the URL from each unsignedresolver is held in the memory of client 103. The process terminatesimmediately if a URL is repeated. If step 358 establishes that aresolver for the account is not stored on the server 110, it returns themessage ‘unknown’ to the client 103.

An alternative pull resolver method allows a resolver to be pulled byspecifying an account name rather than a SecureGUID. This is a bootstrapmethod that is used in the instance that a user informs another user oftheir account name and host server URL. The method is invoked on thisURL. FIG. 5 illustrates the process, in which a client 103 pulls aresolver for a particular account from a server 110. In step 375, thename of the account for which a resolver is required is submitted to theserver, with a 32 bit challenge token. Step 376 checks that the serverhosts a user account with the specified name. The remaining steps areequivalent to the identically numbered steps in FIG. 4. Note that theserver will not attempt to return an unsigned resolver if it does nothost the account. Account names for non-hosted accounts are treated asnon-definitive because they are only unique within the namespace oftheir hosting server.

A resolver for an account may be submitted or pushed into a server. Thisinserts the resolver into the target server's resolver database. Theprocess must take place within a session, which may be either an owneror root session. FIG. 6 illustrates the process, in which a client 103pushes a resolver for a particular account to a server 110. In step 400,client 103 invokes the method on a server 110, parameterized with aresolver and a session nonce. In step 401, server 110 checks that thesession nonce indexes a currently active session. In step 402 the serverchecks that it has not already stored an identical resolver in itsdatabase. A resolver is considered identical if it has identical childand parent fields. If an identical resolver is already stored, theprocess terminates.

In step 407, the presence of a signature in the resolver is checked for.If the resolver is unsigned, it is stored in the resolver database instep 408, flagged as ‘unconfirmed’. If the resolver is signed, itschallenge token is compared to the session nonce in step 403. Theirequality establishes the contemporaneousness of the resolver. Note thatServer 110 needs no knowledge of its actual source, i.e. the particularserver that client 103 has pulled the resolver from. If the challengetoken and session nonce are identical, the resolver signatures arevalidated in step 404. This process is described in the resolversignatures section. Steps 403 and 404 jointly prove that the sourceserver that created the resolver currently has the account private keys.If both steps are is successful, the resolver is stored and flagged as‘confirmed’ and its date checked field is set to the current systemclock time in step 405. If any other resolvers exist for the sameaccount, they are all flagged as ‘unconfirmed’, and their date checkedfields are set to the current system clock time.

A client typically uses the pull and push resolver methods incombination. This allows it to pull a resolver from one server and pushit into another server. This process is applied in two instances. First,user A may have the account name and URL of user B's account. User A mayuse this to pull a resolver for B's account from B's server, and pushthis resolver into their own server. This will allow A to subsequentlylocate B's account, login to it as a guest, and grant permissioncertificates to B. Second, user A may wish to push its own resolver intouser B's server. This allows A to make their identity known on B'sserver. B can subsequently use this to locate A's account and login toit as a guest, and also to grant permission certificates to A. In bothcases, A and B may actually be hosted on the same server. In this case,the respective revolvers are implicitly already present and does notneed to be re-inserted into the resolver database.

FIG. 7 illustrates the process. In steps 454 and 455, a client 103establishes a session on a server 451 using the login method. The typeof session is unimportant. In step 457, client 103 pulls a resolver fromanother server 450, for an account with a specified SecureGUID.Crucially, the challenge token that it specifies is the value of thesession nonce from its session with server 451. In step 458, server 450signs and returns the resolver, including the challenge token field. Instep 459, client 103 pushes the resolver into server 451. In step 460,the resolver is processed according to the steps in FIG. 6.

If a server hosts a given account, it has access to the account'sprivate key. The server uses this key to digitally sign resolvers itreturns in response to pull resolver method calls that specify the givenaccount. This applies to both user and gateway accounts. A server thatcan thus prove possession of an account's private key is considered tobe the authentic location of that account. Signatures are constructed asfollows:

-   -   1. A label that identifies the cryptographic hash and signing        algorithms is created for the signature algorithm field.    -   2. Byte representations of the child, parent, challenge token,        and signature algorithm field are concatenated into a byte array        in a definitive order.    -   3. A cryptographic hash of this byte array is produced,        according to the algorithm referenced in the signature algorithm        field.    -   4. The hash is encrypted using the private key of the account        referred to in the child field, according to signing algorithm        referenced in the signature algorithm field. The result is the        signature field.        The signature algorithm field is a two part identifier that        specifies the combination of algorithms used to produce the        digital signature. The first is an identifier for a        cryptographic hash algorithm to produce a fixed length digest of        the resolver fields. For example, the value ‘SHA1’ could specify        use of the Secure Hash Algorithm 1 (SHA1—as described in U.S.        Pat. No. 4,405,829 ‘Cryptographic communications system and        method’). The second part specifies the asymmetric key        cryptography algorithm that will be used to encrypt the hash        itself, using the respective private key. For example, the value        ‘RSA’ could specify the RSA algorithm (as described in U.S. Pat.        No. 4,405,829 ‘Cryptographic communications system and method’).        The full value of this field would thus be ‘SHA1 with RSA’.

The signature in a signed resolver that is pushed into a server isvalidated before being stored and flagged as ‘confirmed’. The criteriafor successful validation is the equality of the following two values:

-   -   1. The result of decrypting of signature, according to the        specified asymmetric cryptography algorithm, using the public        key contained in the SecureGUID of the resolver's child field.    -   2. The result of the application of the specified hash algorithm        to the concatenation, in canonical order, of byte        representations of the resolver's fields (including the        Challenge token, but excluding the signature).        A background operation processes accumulated resolvers in the        resolver database that are flagged as ‘unconfirmed’. In the        preferred embodiment this is carried out by clients, on the        server to which they are associated. In an alternative        embodiment this may be carried out by the servers themselves or        by other dedicated clients that have an account on a server that        permits the relevant methods.

A list of resolvers that require processing is requested by the agentfrom the server. Theses are resolvers that are flagged as ‘unconfirmed’and whose date checked field is null. For each resolver, the agent pullsa new resolver from its source server and pushes it back into the localserver, according to the process described for the combined pull andpush resolver method. The date checked field for each such resolver isset to the current clock time. Resolvers flagged as ‘unconfirmed’ whosedate checked field is earlier than the system clock time areperiodically garbage collected.

This process ensures three outcomes. First, that confirmed locations areestablished for accounts. Second, that account location changes can besafely learned from resolvers pushed into the server by any agent.Third, the resolver database is optimally pruned on an ongoing basis.

The resolve method returns the URL for a specified account SecureGUID,if a confirmed resolver for this account exists in the resolverdatabase. The method is used by clients to retrieve an account'sserver's URL, prior to invoking any method relating to that account.

A core function of the system is to allow users to securely accesscertain resources in each others' accounts. Aliases allow users topersist (maintain) their own collection of links to other users'accounts. An “alias” is a reference in a source account to a targetaccount. Target accounts may change location without invalidatingaliases, as aliases are merely records of account identities not accountlocations.

An alias is a folder that has a SecureGUID in its alias account field.The SecureGUID is used to initiate a guest login to the target account.The login is invoked at the URL that the resolve method returns whengiven the SecureGUID as a parameter. An alias can be created using theSecureGUID of any target account whose resolver has previously beenstored in the server's resolver database. The alias folder mayoptionally reference a folder in the target account, by storing thetarget folder's identifier in its alias folder field.

A realm is a named collection of folders. Realms expose otherwiseprivate folders to users who have been issued certificates that grantthem access to that realm. Thus, in order to access a folder within aguest session, a certificate for an appropriate realm must have beensupplied within the lifetime of the session. This restriction onlyapplies to guest sessions. In owner sessions, realms are ignored. Zeroor more realms may be defined per account. Realms are non-exclusive,i.e. folders may fall into more than one realm. Also, the same realmname may appear in multiple accounts hosted on multiple servers. Forexample, a realm might represent the distributed resources that allemployees of a multi-divisional company should have access to. Thisrealm may appear in a multitude of accounts of its departments andemployees, hosted across various servers that the company operates. Acertificate that grants permission to a realm allows the bearer toaccess any folder classified in that realm, irrespective of whichaccount uses that realm name to classify folders.

There are numerous possible approaches to classifying resources intorealms. The preferred approach is for the user to define sub-trees oftheir folder directory tree. A particular realm is specified as one ormore realm ‘root’ folders and zero or more realm ‘cut point’ folders.The folder identifiers are stored in a database and associated with arealm name. A realm root folder defines the start point of a realm tree.This folder and its descendants fall within the realm. Multiple rootsmay be specified. For a given realm, a realm root cannot contain anotheras its descendant. A realm cut point defines the end point of a realmtree branch. This folder and its descendants are excluded from therealm. Multiple cut points may be specified. For a given realm, a cutpoint cannot contain another as its descendant. Also, a cut point mustbe a descendant of a realm root.

FIG. 8 illustrates a simple folder tree that has definitions for tworealms, A and B. Realm A has a root at folder 500 and a cut point atfolder 501. Realm A thus contains folder 500, and folders 502 to 505.Realm B has two roots, at folders 501 and 502. Realm B thus containsfolders 501 to 504. The realms overlap, so folders 502 to 504 are inboth realms A and B.

Each realm definition is associated with a globally unique realm name.From a given user's perspective, there are two types of realm name. Thefirst are those that the user originates. The user is the authority oversuch a realm, i.e. access to the realm is within their full control. Theuser has the right to grant other users access to the realm, and tochoose which of these users also has this granting right delegated tothem. The second type are realm names that are originated by otherusers. In this case, the user is not necessarily in a position tospecify which users have permission to the realm. However, they may usethis realm name to expose folders to users that have been granted accessto the realm by its originator (or one of their delegates). This is acrucial feature in reducing the burden of managing secure file sharingbetween distributed users. If a group of N users wish to collectivelyshare resources distributed across their respective N accounts, thenumber of explicit permissions required is N(N−1). If however they alluse a realm name originated by one user, the number of explicitpermissions required reduces to N.

As an example, personnel departments' accounts contain contact lists,i.e. collections of aliases to all staff accounts. Business contactinformation in each staff members' account is classified using anidentical realm, as are the contact lists themselves. Staff across theenterprise are explicitly granted permission to this realm by apersonnel department (or a delegate of it). Staff are thus immediatelyable to access contact information in each others' accounts, wherevertheir accounts are variously hosted. Because of the distributed natureof the realm, each staff member in the hierarchy does not need tohorizontally grant the permission to every other staff member.

A realm name is a composite of the SecureGUID of the realm originator, adescriptive character string, and a serial number. The character stringis typically human readable (for example ‘executives’ or ‘family’). Theserial number is unique across all realms containing the sameSecureGUID. This condition is enforceable because such realm names areby definition created by the same user. The global uniqueness ofSecureGUIDs guarantees that realm names themselves are globally unique.

Realms control the behavior of methods called within guest sessions.Specifically, if a folder management method is parameterized by a noncethat indexes a guest session, permission to the specified folder mustalready have been be established within the session for the method tosucceed. Such permissions are expressed as a list of ‘real stamps’ ineach session state record. The process by which realm stamps areacquired is detailed in the realm stamp method section below.

The process is illustrated in FIG. 9. In step 550, client 103 invokes ageneric folder management method on server 110. It specifies the folderand a session nonce. Step 551 establishes whether the session nonceindexes a currently active owner session. If so, no further checks arerequired and the folder management method completes in step 552, sincean account owner is not restricted in their access to the account'sresources. Failing this, step 553 establishes whether the session nonceindexes a currently active guest session. If it does not, the methodimmediately fails in step 554. If it does, in step 555 a list of allrealms containing the specified folder is created in memory, byreferring to the realm definitions. If the folder is identical to orbelow any realm root, and not identical to or not below a cut point forthe same realm, the folder is considered to be within the realm. Step556 checks that this list is not empty. If it is, the folder isinaccessible to all guest users, i.e. it has not been exposed using anyrealm. The folder management method thus fails in step 554.

If the list is not empty, in steps 557 and 558, the realms in the listare checked for an identical match with any of the realm stamps in thesession state record. A match implies that user has already submitted,within the session, a certificate granting them access to one of therealms containing the folder. The method succeeds in step 552. If afolder is within multiple realms, it is only necessary for the guestuser to have a realm stamp for one of these realms to have access to it.However, if the folder management method is either write header, writedata, remove folder, or remove data, the realm stamp must state a‘read/write’ permission. If no match exists, the method fails butnevertheless returns the list of realms that contain the specifiedfolder. The user will subsequently invoke the realm stamp method tosubmit a certificate for one of the realms in the list, if such acertificate is available to the user. The session state maintained onthe target server contains a list of accumulated realm stamps. Theserecord the fact that the guest user has provided certificates for theserealms and that the certificates were successfully validated by thetarget server.

Users may be granted access to a realm by another user. A certificate isan expression of a permission to a named realm. It grants access to allfolders classified in the named realm, in any account. The permission isgranted by the user who originates the realm name. The recipient mayreceive the certificate directly from the originator, or via any numberof intermediary ‘delegates’.

A certificate consists of an ordered sequence of individual ‘grants’.Within a certificate, each grant refers to the same realm. In eachgrant, an issuing user grants a recipient user the permission to accessthe realm. In the case where the realm originator issues the certificatedirectly to the user, there is only one grant. This is the ‘realmoriginator grant’. In the case where there are intermediate delegates,there will be one or more grants appended to this grant. Each grantstates whether its recipient can act as a ‘delegate’. If this is thecase, the recipient may issue certificates for the realm to otherrecipients, by appending another grant to their own certificate.

Each grant comprises the following fields:

-   -   1. Issuer    -   2. Recipient    -   3. Realm Name    -   4. Delegation Right    -   5. Access Mode    -   6. Expiry Date    -   7. Algorithm    -   8. Signature        Whereas a certificate is a chain of separate grants each having        a recipient, the ‘recipient’ of the certificate is defined as        the recipient of the final grant. Similarly, the ‘issuer’ of the        certificate is the issuer of the final grant.

Certificates and grants are in the public domain. Identical copies of aparticular grant may be present on any number of servers with nonegative impact on security. A grant is only effective when it is thefinal grant in a certificate presented by the realm stamp method withinan active guest session. The private key of the guest must necessarilyhave been used to activate the session, and the certificate is onlyaccepted if the recipient of its final grant is identical to theSecureGUID of the session initiator. Thus, only the recipient of thefinal grant of a certificate may successful submit the certificatewithin a guest session. A description follows of each field in a grant.

Grant-Issuer This is the SecureGUID of the account belonging to the userwho is granting the permission. Grant-Recipient This is the SecureGUIDof the account belonging to the user who is receiving the permission.Grant-Realm Name This is the name of the realm for which permission isbeing granted. In the case of a realm originator grant, the SecureGUIDpart of the realm name will be identical to the issuer SecureGUID.Grant-Delegation This is a non-negative integer. A non-zero valuerepresents the Right right of the recipient to appear as the issuer of asubsequent grant in a certificate. The delegation right in each grantwithin a certificate must decrement by at least one the delegation rightin the previous grant within the certificate. This allows a distributionof responsibility for granting realm permission, i.e. a realm originatormay entrust other users the right to grant permission to that realm. Forexample, a realm for executives may be originated by head office.Certificates for this realm may be issued to divisional heads. If thegrant in these certificates has a non-zero delegation right, thedivisional heads may issue certificates for this realm to their staff.These certificates would each append a second grant to the first. Thesemay in turn have a non-zero delegation right, allowing the creation offurther certificates containing three or more grants. Grant-Access ModeThe value of this field is either ‘read’, ‘read/write’, or ‘transfer’.This determines the type of method that the recipient can invoke onfolders within the named realm. A value of ‘read’ allows retrieval offolders only, i.e. the methods to read a header, read data, and readchildren. A value of ‘read/write’ additionally allows the methods towrite a header, write data, remove a folder, and remove data. The valueof ‘transfer’ is reserved for the account migration process, detailed inthe migration section. If the grant has a non-zero delegation right, thegrants that the delegate appends have a restriction with respect toaccess mode. This restriction states that a grant with ‘read/write’access mode cannot be appended to a grant with ‘read’ access mode.Grant-Expiry Date The expiry date is chosen to represent the minimumperiod within which the permission is not expected to need revoking. Theformat of this field is defined by ISO 8601: 1988 (E) “Data elements andinterchange formats - Information interchange - Representation of datesand times”. The expiry date does not imply the actual point at which theissuer wishes the permission itself to terminate. Grants are updated bya background process described elsewhere in this specification. Thegrant may, for instance, have a short expiry yet be repeatedly updatedby the issuer over a long period. The grant's expiry date merely limitsthe time validity of the currently held expression of that permission.It allows the issuer to specify a maximum interval within which thegrant may remain valid following revocation, if revocation is not beingexplicitly checked for. Grant-Algorithm This two part identifierspecifies the combination of algorithms used to produce the grant'sdigital signature. This is equivalent to the algorithm fields in aresolver, described in the resolvers section. Grant-Signature Thesignature is the result of encrypting a hash of the grant fields. Theprocess that produces it is as follows: 1) Byte representations of thegrant fields (excluding the signature) are concatenated into a bytearray in a predetermined order. 2) A hash of this byte array is producedusing the algorithm specified by the grant's algorithm field. 3) Thishash is encrypted using the private key of the grant issuer, accordingto the algorithm specified by the grant's algorithm field.A user may present certificates during a guest session using thismethod. If the certificate is valid (see certificate validation processsection) and identifies the guest user's SecureGUID as the recipient ofits final grant, the realm name and access mode from the certificate isentered into the stamps field of the session state record. This willpermit the guest user to access folders within the realm, according tothe methods permitted by the access mode specified in the certificate.The guest user has already been authenticated, when activating the guestsession.

The method takes a session nonce and a certificate as parameters. Theinitiator SecureGUID in the session state indexed by the nonce iscompared to the SecureGUID of the recipient of the final grant in thecertificate. If these are identical, the certificate is considered tobelong to the guest user. The certificate is validated using thecertificate validation process. If it is valid, the realm name is addedto the ‘stamps’ field of the session state record.

A certificate is considered valid if each of its grants meet certainconditions, as well as certain conditions regarding theirinterdependency. The certificate validation process is applied to theordered chain of grants in the certificate. The validation condition areas follows:

1) The realm name is identical in each grant.

2) In the first grant, the SecureGUID part of the realm name isidentical to the SecureGUID of the issuer.

3) The SecureGUID of the issuer of each grant is identical to theSecureGUID of the recipient of the previous grant, if there is such agrant.

4) The delegation right of each grant decrements by at least one thedelegation right in the previous grant, if there is such a grant.

5) The delegation right of each grant is a non-negative integer.

6) The access mode of each grant is either ‘read’ or ‘read/write’.

7) The access mode of any grant cannot be ‘read/write’ if it is precededby a grant with an access mode of ‘read’.

8) The expiry date of each grant is ahead of the current system clocktime.

9) In each grant, the following two values are identical:

-   -   i) The result of decrypting of signature, according to the        specified asymmetric cryptography algorithm, using the public        key from the issuer's SecureGUID.    -   ii) The result of the application of the specified hash        algorithm to the concatenation, in canonical order, of byte        representations of the grant's fields (excluding the signature).        While a certificate may be valid according to the validation        criteria, the issuer of a particular grant within it may since        have revoked the permission to the realm, as described in the        revoke grant method section. In the preferred embodiment, such a        vestigial grant is nevertheless considered valid up to its        expiry data. Revocation is experienced as a failure to retrieve        an updated grant, as described in the retrieve grant method        section.

In a critical security situation, revocation may be required to haveimmediate impact. Thus in an alternative embodiment of the system, acertificate presented during a guest session for access to a realm isconsidered only to be evidence of permission, not a permission itself.In this case, the server would not validate the certificate's actualgrants, but would itself anonymously request copies of each grant inturn directly from their respective issuers. This is achieved using theretrieve grant method section, and requires that the submittedcertificate be bundled with (unsigned) resolvers for the issuer of eachgrant it contains. Resolvers for grant issuers that are not alreadyresolvable are pulled using the pull resolver method, invoked at theirhost servers locations as suggested by the supplied un-signed resolvers.This process rebuilds a chain of fresh grants, if no recipient has beenrevoked. The validation process is thereafter identical.

A user will be the recipient of a number of certificates, pushed totheir server by other users as described in the push certificate methodsection. The grants contained in the certificate are stored asindividual records in a grant database on the server. The sense of theirchaining together to form a particular certificate is not maintained.

The certificates that users of a given server collectively receive arelikely to have grants in common. Particularly, any grant with a non-zerodelegation right will appear identically in all certificates that werecreated by appending grants to it. The grant database will not holdmultiple copies of grants with identical essential attributes. Theseessential attributes are issuer, recipient, and realm name. When areceived grant's essential attributes are identical to those of a storedone, priority is given to the higher delegation right, then to the laterexpiry date.

Increasing the delegation right of a stored grant in this way may alterthe result of subsequent extractions for certificates that contain thegrant as a delegate. For a given realm and final recipient, a differentancestry of grants may be extracted. This has no impact on the validityof the certificate. Also, it does not unduly improve the certificate's‘power’ with respect to delegation right, as this is always constrainedby the value of the delegation right in the final grant.

A server may store multiple grants for a given recipient and realm name,if their issuer fields differ. This accommodates a user receivingcertificates for a given realm from multiple issuers. However, only onesuch grant is chosen as the user's appointed issuer of permission forthat realm. Each grant record has a flag in the database indicating itsstatus, the possible values of which are ‘unconfirmed’ and ‘confirmed’.A confirmed status indicates that the grant expresses the recipient'schoice of issuer for permission to that realm. Confirmed grants are theones that new grants issued by delegate users are appended to. Grantstatus is by default ‘unconfirmed’. Strictly one grant per recipient andrealm name combination may be flagged as ‘confirmed’. Additionally, eachgrant record has a ‘date checked’ field. This is a time stamp whichmarks the moment when the status of the grant is determined. The statusflag and date checked field both relate to the recipient's usage of thegrant, and are not specified by the grant's issuer.

In the preferred embodiment, the status is immediately determined in thecase that the recipient of an incoming grant is hosted on the serveritself. The grant record's status flag is immediately set to ‘confirmed’if it is the first grant that is pushed to the server for a particularrecipient and realm name combination. The status of subsequentlyreceived grants for the same recipient and realm name combination is setto ‘unconfirmed’. In both instance the date checked field is set to thecurrent time. In an alternative embodiment, the user may participate inthe choice of issuer for permission to a realm. In other words, the usermay choose or alter at a later date which grant to flag as ‘confirmed’from amongst multiple grants for identical realm names, for which theyare the recipient. When the recipient of an incoming grant is not hostedon the server, its status flag is set to ‘unconfirmed’ and its datechecked field is set to null. Such a grant will subsequently passthrough the process described in the grant maintenance section toestablish its status.

An ‘access control grant’ is a grant issuer's own of a grant. Thesegrants are regularly re-signed to keep their expiry dates valid, asdescribed in the re-signing section. They are deleted if the recipientdoes not choose the issuer as their appointed issuer for a particularrealm, as described in the garbage collection section.

These grant records make use of two additional fields, ‘expiry period’and ‘cancellation date’. The expiry period is a time value which isadded to the current time to produce an expiry date, at the moment thata such a grant is signed. The cancellation date is the time after whichthe grant will not be re-signed.

The push certificate method is used by a client to insert a certificateinto a target server. The client is acting on behalf of the issuer ofthe certificate, and pushing it to the server on which the certificate'srecipient is hosted. FIG. 10 illustrates the process. In step 600, aclient 103 invokes the push certificate method on a server 110,parameterized with a session nonce and a certificate. Step 601 checksthat the session nonce indexes an active session. Step 602 checks thatthe certificate's issuer (i.e. the issuer of the its last grant) isidentical to the initiator SecureGUID in the session state indexed bythe nonce. Step 603 checks that account of the certificate's recipient(i.e. the recipient of the its last grant) is hosted on the server.

Step 604 checks that the certificate's issuer is resolvable on theserver. This condition is crucial for the subsequent renewal of grants,as described in the grant maintenance section. If it is not resolvable,the method will fail and the client must push a resolver for the issuerto the target server before retrying, using the process described in thecombining pull and push resolver methods section.

Step 605 checks that the certificate is valid according to the criteriadescribed in the certificate validation process section. If all theseconditions are met, the grants contained in the certificate are storedby the server in step 613. The steps 608 to 612 are individually appliedto each grant in the certificate. Step 608 checks that the grant'srecipient is hosted on the server. If it is not, it is stored in step610 with its status flag set to ‘unconfirmed’ and date checked field setto null. If the recipient is hosted on the server, step 609 checks thatit is the first grant with the given recipient and realm namecombination. If so, it is stored in step 612 with its status flag is setto ‘confirmed’ and date checked field set to the current system clocktime. If not, it is stored in step 611 with its status flag is set to‘unconfirmed’ and date checked field set to the current system clock.

The issue grant method creates and stores an access control grant in theissuer's own grant database. It will only succeed if parameterized by anonce indexing an active owner session. The method takes the parametersrecipient SecureGUID, realm name, delegation right, access mode, expiryperiod, and cancellation date. The issuer of the created grant will beinitiator SecureGUID in the session state indexed by the nonce.

If the issuer is identical to the SecureGUID part of the realm name, arealm originator grant is created, without restriction on the otherfields in the grant. If these are not identical the issuer is acting asa delegate, and must have the necessary permission to create the grant.The server will check that the issuer itself has a grant for the realmwith non-zero delegation right greater than the specified delegationright parameter. Also, this grant must have ‘read/write’ access mode ifthis is the mode specified in the access mode parameter. The method willfail if these conditions are not met.

The client will follow this process installing a complete certificate onthe server hosting the grant's recipient account. The certificate willhave the newly created grant as its final grant, with supporting grantsto provide a valid chain. This is retrieved using the retrievecertificate method, and then pushed to the target server using the pushcertificate method.

The revoke grant method disables an access control grant from theissuer's own grant database, by setting its cancellation date field tothe current clock time. The method takes as parameters a session nonce,recipient SecureGUID, and realm name. It will only succeed ifparameterized by a nonce indexing an owner session. The method acts uponany record in the grant database matching these respective fields, withissuer equal the Initiator SecureGUID in the session state indexed bythe nonce.

The retrieve certificate method returns a complete certificate from thegrant database, comprising one or more grants. The method does notrequire a session nonce parameter, as grants are in the public domainfor reasons detailed in the Certificates and Grants section. The methodtakes as parameters the SecureGUID of the recipient of the requiredcertificate, a realm name, and optionally the SecureGUID of the issuer.The method is invoked in two instances. First, to retrieve a certificatethat the user is the recipient of, so that they may gain access to arealm in a simultaneous guest session. In this case, the issuerparameter need not be specified. Secondly, to retrieve a certificatethat the user is the issuer of, to subsequently push it into therecipient's server. In this case, the issuer parameter is specified.

FIG. 11 illustrates the process. In step 650, a client 103 invokes theretrieve certificate method on a server 110. In step 651 a grant isretrieved, if it exists, from the grant database. If the SecureGUID ofthe issuer is not specified, the grant that is retrieved will be the oneflagged as ‘confirmed’ which matches the specified recipient and realmname. If the SecureGUID of the issuer is specified, the grant that isretrieved will be the one which has the specified issuer, recipient, andrealm name. Step 652 checks if this is a realm originator grant (i.e.its realm name SecureGUID matches its issuer SecureGUID). If so, thecertificate consists of only one grant and is returned in step 653. Ifnot, the process is recursive. Step 651 is repeated, with recipient nowequal to the issuer of the previously retrieved grant. Thus forpreviously retrieved grant A, a grant B is retrieved whose recipient isthe issuer of grant A. In the certificate, B will precede A. Grant Bmust strictly have a delegation right higher than A's by at least one.Grant B must also strictly have a ‘read/write’ access mode if this isA's access mode. Only grants with valid expiry dates are considered.This recursion continues until a realm originator grant is found.

If a valid chain of grants cannot be constructed, the method fails. Itshould be noted that there is not necessarily a single unambiguous chainof grants. For a given recipient and realm name combination, there maymultiple grants with differing issuers. Multiple valid chains may beconstructed in this case. If grants are flagged as ‘confirmed’, theywill be chosen in preference to those flagged ‘unconfirmed’, althoughthis is not critical as any valid chain will serve the required purpose.

The retrieve grant method requests a copy of a specified grant from thegrant database. It is invoked as part of the process described in thegrant maintenance section. Its function is to retrieve a copy of a grantfrom the server of either the grant's issuer or its recipient. Themethod takes as parameters the SecureGUIDs of the recipient and issuer,and a realm name. The method does not require a session nonce parameter,as grants are in the public domain for reasons detailed in thecertificates and grants section. A grant is retrieved, if it exists,from the server's grant database. It must be flagged as ‘confirmed’, andmatch the specified recipient and realm name. If the SecureGUID of theissuer of the grant is identical to the method's issuer SecureGUIDparameter, the grant alone is returned.

If the issuer of the is grant is not identical to the method's issuerSecureGUID parameter, the grant's recipient has in the interim chosen adifferent issuer as their appointed issuer for permission to the givenrealm. This is either because their permission was revoked by theirprevious choice of issuer but still available from another issuer, orbecause the user explicitly chose a new issuer according to thealternative embodiment referred to in the Grant Storage section. In thisinstance, the grant and its supporting grant chain is retrieved andreturned in an equivalent manner to that described in the retrievecertificate method section. If the recipient has been revoked (i.e. thecancellation date for the requested grant is earlier than the currenttime) or the grant does not exist, the retrieve grant method returns arevocation exception.

Three background grant maintenance processes ensure that grant databasesare kept up-to-date on each server. These are carried out automaticallyon individual grants, i.e. reference is not made to the chains whichgrants may be constituents of. The first process keeps access controlgrants current by re-signing them with new expiry dates as they expire.The second process retrieves replacement grants from other servers tomaintain valid expiry dates, and also establish values for their statusflags. The third process garbage-collects redundant grants. These threeprocesses ensure that permissions granted by users hosted on the serverdo not unduly default, that users may retrieve valid certificate chainsfrom the grant database on an ongoing basis if no revocations have takeneffect, and that the grant database is kept optimally small.

In an alternative embodiment these functions may be carried out by theservers themselves, acting as clients to other servers. In the preferredembodiment, the second function (grant renewal) is carried out by theserver's associated client, or a dedicated maintenance client whose ownaccount has the necessary permissions. This acknowledges the scalabilityproblems that may result from having multiple concurrent processesrunning on a traffic intensive server.

A grant is characterized by four Boolean states which jointly determinewhich of the maintenance processes are applied to it, namely:

a) Recipient is hosted hereb) Issuer is hosted herec) Status flag equals ‘confirmed’d) Date checked does not equal nullFIG. 12 specifies the processes applied to each grant according to theircombination of these states. Garbage collection is applicable to allgrants given certain conditions, so is not listed as a process in thetable. Note that some combinations of states are not possible.Particularly, if a status flag is ‘confirmed’ it cannot also have a nullvalue for its date checked field. Also, if a grant's recipient is hostedon the server itself, its date checked flag is necessarily not null forreasons described in the grant storage section. The three maintenanceprocesses of re-signing, grant renewal, and garbage collection aredetailed below.

1. Re-Signing of Access Control Grants

Access control grants whose expiry date is imminent are given a newexpiry date and re-signed, if their cancellation date field is laterthan the current system time. The new expiry time is the lesser of thecancellation date, or the sum of the current time and the expiry period.The new grant signature is created as described in the grant signaturedescription. The server necessarily has the private key required tocreate the signature, since it hosts the account of the issuer of allaccess control access control grants in its database. The status flagand date checked fields are not altered by this process. If an accesscontrol grant's cancellation date field is earlier than the currentsystem time, it is ignored by the re-signing process. The garbagecollection process will identify it for removal.

2. Grant Renewal

Grants that require renewal are those that are:

-   -   a) flagged as ‘confirmed’ and approaching expiry (unless both        recipient and issuer are hosted on the server) and;    -   b) flagged as ‘unconfirmed’, whose date checked field equals        null.        For each such grant, a renewal is requested using the retrieve        grant method. The location at which the retrieve grant method is        invoked depends on whether or not the recipient of the grant is        hosted on the server itself. If the recipient of the grant is        hosted on the server, the grant has the role of a final grant in        a certificate previously pushed to the server. The retrieve        grant method is invoked on the server of the grant's issuer to        acquire a renewal, i.e. a hopefully-new copy of the access        control grant. The returned grant will overwrite its expiring        counterpart if it is identical in its essential attributes.

If recipient of the grant is not hosted on the server, the grant has therole of a delegate grant within a certificate previously pushed to theserver. The retrieve grant method is invoked on the server of thegrant's recipient to acquire a renewal, i.e. a copy of the recipient'scopy of that grant. This represents the recipient's choice of appointedissuer for permission to the given realm. If a retrieved grant isidentical in its essential attributes it overwrites its expiringcounterpart (unless it is also an access control grant, i.e. the issueris locally hosted). Its status flag is set to ‘confirmed’, and its datechecked field is set to the current clock time. If the recipient hasbeen revoked, the returned grant will not have a renewed expiry time ormay be null if it has been garbage collected. The date checked field forthe grant record is set to a time later than the expiry date of thegrant. The garbage collection process will thus identify it for removal.

If the grant's recipient has since chosen a different issuer forpermission to the realm, the retrieve grant method will instead return acertificate, i.e. a chain of grants that support a new final grantembodying the new choice of issuer. The existing grant's status flag isset to ‘unconfirmed’, and its date checked field is set to the currentclock time. The returned chain is stored on the server as described inthe grant storage description, unless the existing grant is an accesscontrol grant.

3. Garbage Collection

Grant records are garbage collected from the database in the threefollowing cases:

a) Redundant grants, i.e. those that have been rejected in favor ofanother issuer for the given realm. These are grants whose status flagis ‘unconfirmed’ and whose date checked field is non-null. In analternative embodiment of the system, these are not garbage collecteduntil their expiry data, giving the user the chance to switch to usingthem as the preferred issuer for the realm. Note that this includesrejected access control grants, i.e. those that are not flagged as‘confirmed’ on their recipient's server. Such grants do not embody therecipient's choice of issuer for a given realm.

b) Revoked grants, i.e. those that could not be renewed. These aregrants whose date checked field is later than their expiry date field.

c) Revoked access control grants, i.e. those that should not longer bere-signed. These are grant records whose cancellation date is earlierthan the current system clock time.

During the renewal process, there will be instances where a grantrecipient is not resolvable. In other words, it will not beascertainable which server to retrieve a new grant from. Specifically,the recipient quoted in a grant having a delegate role within a chaincertificate is not necessarily resolvable by the server onto which thecertificate is pushed.

However, the issuer of the final grant in this certificate isnecessarily resolvable on the server, for reasons described in the pushcertificate method section. This account is identical to the recipientof the penultimate grant. The SecureGUID of the recipient of any grantin a chain is thus always resolvable by the server hosting the recipientof the grant below it in a chain of grants forming a certificate.

If a grant recipient's SecureGUID turns out to be irresolvable, theprocess retrieves a list of the recipients of all grants that quote thisaccount as their issuer. One of these may be resolvable. If so, aresolver is pulled from its server for the SecureGUID of the locallyun-resolvable grant. If not, the grant renewal is deferred until thenext cycle of the renewal process. This ensures that resolvability ofall grant recipients is ensured over successive cycles of the backgroundgrant renewal process. This ‘trickles up’ through the recipients of allgrants in a chain, starting from the final grants which is alwaysnecessarily resolvable for reasons described in the push certificatemethod section.

The push grant method is used by clients carrying out the serveradministration process described in the grant maintenance section. Themethod inserts into the grant database a grant, previously collectedfrom another server using the retrieve grant method. The method willonly succeed if parameterized by a nonce that indexes an active ownersession for a gateway account. Such an account has the privilege ofbeing able to specify values for a status flag and date checked value,overriding the defaults employed by the push certificate method. Themethod takes as parameters a session nonce, a grant, a status flag, anda date checked value.

To transport a grant, i.e., marshal a grant or a chain of grants forminga certificate across a network connection within the body of a remoteprocedure call, an XML (eXtensible Markup Language) representation of itis produced. Representations of the signatures, UUIDs, and public keysare coded in as Base64 (defined in RFC-1341 ‘Multipurpose Internet MailExtensions: Mechanisms for Specifying and Describing the Format ofInternet Message Bodies’, section 5.2).

A user may migrate their account between servers without relinquishingthe account's SecureGUID and private key. The process involves thefollowing steps. The user is assumed to currently own account A, hostedon a source server, which is to be migrated to a destination server.

a) Account A's entire assets are exported to an intermediary fileformat, using the method described in the export method section.

b) A new account, B, is created on the destination server.

c) A ‘transfer’ certificate is issued by account A to account B, andpushed to the destination server. This consists of a single realmoriginator grant whose access mode is ‘transfer’. The certificate is apermission for account B to appropriate account A's identity, signed byaccount A's private key.

d) By presenting the transfer certificate, the private key of account Ais retrieved from the source server by the client acting on behalf ofaccount B. This key is encrypted using account B's public key. Thesource server thus relinquishes the hosting of account A. This processis detailed in the release identity method section.

e) On the destination server, the returned encrypted key is decryptedusing account B's private key. Account B's SecureGUID identity isreplaced by that of account A, and its private key is replaced by thatof account A. The process is detailed in the switch identity methodsection.

f) Account A's assets are imported from the intermediary file format,using the method described in the import method section.

The export method retrieves all the assets from an account and returnsthem as a single XML export file. The method participates in the accountmigration process. The method is parameterized by a session nonce, whichmust index an owner session. The following assets from the account ofthe session owner are included in the XML export file:

a) the account's folder structure;

b) the account's folder data;

c) all access control grants issued by the account;

d) all grants that are constituents of all certificate chains whosefinal grant recipient is the account;

e) all resolvers for issuers of final grants in such chains;

f) all resolvers for aliases in the account's folder structure.

The method and may also be used to allow a user to store a backup oftheir account onto another system such as a desktop computer.

The import method retrieves account assets from an XML export file andenters them into an account. The method participates in the accountmigration process. The method is parameterized by a session nonce and anXML export file. The nonce must index an owner session. The method addsthe assets to the account of the session owner. The following methodsare employed to enter the respective assets from the XML export file:write header method, write data method, push certificate method, andpush resolver method. The method and may also be used to allow a user torestore a local backup to their account.

The release identity method participates in the account migrationprocess, and is the first stage of transferring an account identity froma source server to a destination server. It is invoked on the sourceserver, by the client associated with the destination server, on behalfof an account B. It releases the identity of an account A so that it maybe appropriated by account B. The method returns the private key ofaccount A encrypted with the public key of account B, stores an unsignedresolver for the subsequent location of account A (i.e. the currentlocation of account B), and causes the deletion of account A's folders.The method is parameterized by a session nonce and a ‘transfer’ grant ofthe type detailed in the migration section. The nonce must index a guestsession. The session owner, Account B, must be resolvable on the server,and must be the recipient of the submitted grant. The issuer of thegrant, account A, must be hosted on the server. The submitted grant musthave an access type of ‘transfer’ and must be an unexpired realmoriginator grant. The private key of the account A is encrypted usingthe public key of the account B (this being part of account B'sSecureGUID). This encrypted key is returned in the method's response.

A locator is created on the server, mapping account A to the currentlocation of account B. Note that account B is already resolvable by theserver, as a precondition of the method. The server will from this pointon respond to pull resolver method invocations for account A with an(unsigned) resolver indicating its new location. Account A's folders,and access control grants issued by A, are flagged for garbagecollection from the database by a background process.

The switch identity method participates in the account migrationprocess, and is the second stage of transferring an account identityfrom a source server to a destination server. It is invoked on thedestination server by its associated client, on behalf of an account B.The method substitutes account B's SecureGUID and private key, in favorof a supplied SecureGUID and private key. These previously appropriatedfrom an account A using the release identity method. The switch identitymethod is parameterized by a session nonce, the SecureGUID of account A,and the encrypted private key of account A. The nonce must index anowner session. The session owner, i.e. the initiator SecureGUID in thesession state indexed by the nonce, indicates the account B whoseidentity is to be changed. The server uses the private key of account Bto decrypt the encrypted private key of account A. The private key ofaccount B is replaced by the private key of account A. The SecureGUID ofaccount B is replaced by the SecureGUID of account A. If there exists aresolver indicating the former location of account A, this resolver isdeleted from the destination server's database.

In the preferred embodiment, the user is presented with interfacesrunning within a browser or device capable of rendering markup language(such as HTML, WML, or VoiceXML). These front end applications that usethe application programming interface of this description, isolating theuser from the details of the various method calls. The user can thusnavigate through their account's folder tree, read, replace, add, anddelete folders. Additionally, via the interface the user can pull theresolvers of other users, push their own resolvers into other users'servers, create aliases, and initiate guest sessions to other usersaccounts. Users can browse the folders in other users accounts to theextent that they have been granted the right to do so in previouslyacquired certificates. Additionally, the user can, via the interface,define realms within their account and manage the issuing and/orrevocation of certificates for other users.

Applications of the present invention are not limited to Internet filesharing. Small hand held computers are commonly used to maintain contactlists, just as cellular phones have memory in which to store commonlydialed numbers. However, data entry directly into these devices is quitedifficult and laborious. Editing of a contact list file for a small handheld computer can be carried out by exporting the file to a desktopcomputer, entering the changes, and then saving the file to the handheld computer, but this is a cumbersome process in its own right.

The present invention makes it possible to maintain contact files of allkinds without the need to manually reenter duplicate data into otherdevices, and with the capability to make immediately available anychanges or updates of the data made by other users. For example, a userupon purchasing a cell phone maintains as files on a network accordingto the invention both a contacts list and contact information. Thecontact information contains the user's current phone number. Thecontacts list contains names and phone numbers that the user has saved.However, such names and numbers need not be saved as is, but instead asa series of links to the contact information of other users, stored in afolder in an accessible realm in those users' own accounts. To obtainthe number, the phone transmits a request to a program running on thenetwork, which returns the current information stored for the person theuser is calling and dials their current number, or returns their currentnumber permitting the user to dial it. Any change in phone number whichhas occurred is retrieved and, indeed, the user may not even notice thata new number was dialed, or even be aware that the account of the personthe user is calling may itself have migrated to another server.

As to contact information, when the user needs a new phone, and possiblya new phone number as well, the transition is easily accomplished sincetheir user ID number (e.g., SecureGUID) remains the same. The new phoneaccesses the existing contact list stored on the server, not on thephone, so no manual re-entry of contact information is necessary. Thenew phone number is posted to the user's contact information folder.Other users with permission to access that folder will subsequentlyobtain the new number. The new number can be posted to a folderclassified in a well-known realm (e.g., for all customers of thecellular provider or the staff of a particular company, in the manner ofa telephone directory) or a privately defined realm (e.g., for familyand friends chosen specifically by the user.) Since the same folder maybe included in more than one realm, the user's contact information maybe classified in several realms. Thus, the system of the invention canprovide applications including self-updating corporate address books andself-correcting customer lists.

Contact information may include just phone number(s), in the case of anetwork created for telephone contacts only, or may include othercontact data such as postal address. The user then can then make thisinformation available to creditors, correspondents and the like, so thatchange of address data is immediately available to each entity havingaccess to the user's contact information folder, without going throughthe arduous process of manually notifying contacts of an address change.

The invention provides an integral system and method to create acenter-less network of private resources. Such resources may be securelyexposed by a user to certain other users, irrespective of where theirrespective accounts are hosted. These users may switch service providerwithout loosing their permissions. These permissions, themselvesdelegable, grant access to resources that may be distributed acrossmultiple accounts across the network. While the above descriptioncontains many specifications, these should not be construed aslimitations on the scope of the invention, but rather as exemplificationof one of the preferred embodiments thereof. Within the scope of thedescription itself, many implementation alternatives exist. For example,whilst the preferred embodiment makes use of HTTP and SOAP to enable theremote invocation of methods, it may equally use object request brokertechnologies such as RMI and CORBA, or remote procedure call methodssuch as XML-RPC. Beyond the scope of the detailed description, manyother variations of the application of the security model are alsopossible. For example, the preferred embodiment is concerned with themanagement of access to static files structured in a hierarchy offolders. The invention could equally be applied to the management ofaccess to other resources, for example application objects, networkservices, or dynamic content. Accordingly, the scope of the inventionshould be determined not by the embodiment illustrated, but by theappended claims and their legal equivalents.

1.-16. (canceled)
 17. A system for maintaining contact information,comprising: a server; a network permitting data communication betweenthe server and a number of electronic devices that maintain or usecontact information; and a plurality of user accounts hosted on theserver, each account containing a contact information listing currentcontact information for the associated user, and a contact list ofidentifiers for other users also having accounts on the server, whichthat user has selected.
 18. The system of claim 17, further comprisingmeans for a first user account to grant a second user account permissionto access the first user's contact information.
 19. The system of claim17, wherein the user controlled electronic devices are portabletelephones enabled with client functionality.
 20. The system of claim17, wherein the user controlled electronic devices are personalcomputers enabled with client functionality.
 21. The system of claim 17,wherein the system includes a plurality of servers, the network permitsdata communication between a client electronic device and each server,and user accounts are hosted on each server. 22.-30. (canceled)
 31. Asystem for maintaining contact information for telephones, comprising: aserver; a network permitting data communication between the server and anumber of client telephones enabled with client functionality that usecontact information, which contact information includes telephonenumbers that can be dialed by the client telephone; and a plurality ofuser accounts hosted on the server, each account containing stored datacomprising contact information for the associated user and a contactlist of telephone numbers which can be dialed by the user from theclient telephone.
 32. The system of claim 31, wherein the telephones arewireless portable telephones, wherein the contact information for theassociated user includes a user ID that remains the same when the userchanges wireless portable telephones.
 33. The system of claim 31,further comprising a program that receives a request for a contacttelephone number through the network from a client telephone, whichprogram returns current information stored for the requested contact tothe client telephone.
 34. The system of claim 31, wherein the contactlist includes identifiers for other users also having user accounts,further comprising means for a first user account to grant a second useraccount permission to access the first user account's contactinformation.
 35. The system of claim 34, further comprising a programthat receives a request for a contact telephone number through thenetwork from a client telephone, which program returns currentinformation stored for the requested contact to the client telephone.36. The system of claim 35, further comprising means permitting thesecond user to change a telephone number for the second user stored inthe first user's contact list.
 37. A method for maintaining contactinformation for a number of users having accounts on a network, thenetwork comprising a number of client telephones that use stored contactinformation including telephone numbers for dialing, a server on whichthe user accounts are hosted, and means permitting data communicationbetween the server and the client telephones, comprising the steps of:maintaining for each user account current contact information for theassociated user; and maintaining a contact list of telephone numberswhich that user has selected, which contact list can be accessed anddialed by the client telephone used by that user.